…ge gate did its job

Merge origin/main and record the first live graduation: #4165 made the app
shell strict while this PR was in CI. The derivation adapted on its own — app
fell out of the lintable set because its parse is now loud — and the pinned
expectation list is what turned that shrink into a red test instead of a silent
one. That is the exact scenario the pin exists for: a human confirms the shrink
is a graduation, not a regression, and moves the name from the covered list to
the strict list.

Changeset and docs updated to stop hardcoding the count and the strict roster —
both now describe the rule (the strict bucket grows as tiers graduate) rather
than a snapshot of it.

7133 tests green on the merged base; all six gates PASS; the three example apps
stay clean.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01UXGj3Z5TmwSV6RK2oGc3cb

…ection (#3786) (#4178)

#4148's lint covered object and field — a sample, not the population: only a
handful of authorable types are .strict(); every other type strips an
undeclared key with no signal. The walker now covers every lintable collection
(16 today), with its coverage DERIVED, not listed: collections from
PLURAL_TO_SINGULAR, the judging schema from the type→Zod registry, and
lintability read off each schema's own unknown-key posture (strip → lint;
strict → skip, the parse is loud; passthrough → skip, nothing is dropped;
unions → member-key union).

The walker lives in kernel/ beside the schema registry; the comparator and
guidance tables stay in data/, frontend-safe. Root export unchanged, so
defineStack, os validate and os build pick the coverage up with no change.

Mid-review, #4165 graduated `app` to strict — the derivation adapted on its
own, and the pinned coverage expectation turned the shrink into a red test
until a human confirmed it was a graduation, not a regression. That is the
gate working as designed; the strict roster in the test now records it.

Verified clean against the three example apps (zero false positives), by
mutation in three directions, and 7133 spec tests green on the merged base.

…itten doc (#4177)

The liveness gate asks whether a property does anything; check-doc-authoring asks
whether docs use the right authoring form. Neither asked the inverse-drift question:
does a variant the schema DECLARES appear in the prose at all? content/docs/references/
is generated from these schemas and cannot drift; the hand-written pages are typed by
humans and do.

Founding case, which shipped for months: apps.mdx said the navigation tree "supports
eight item types" and enumerated eight. The schema had nine — `separator` was added to
match the objectui renderer (#1878/#1891/#1894) and no hand-written page ever learned
about it. #4165 raised the cost: a mistyped discriminator now answers with the list of
valid values, and the doc's enumeration is what an author checks it against.

Identity is `<discriminator>:<variants sorted>`, deliberately not a source path — a union
is reachable by several paths and the walk order picks one. Keying on the variant set
means adding or removing a variant changes the key, failing the ratchet and sending the
author back through the ledger to the doc.

variant-docs.json classifies all 20 unions found by reflection (a count that matches
`grep -c 'z.discriminatedUnion('` exactly): 5 governed, 15 exempt as either
generated-reference-only or not-authorable.

Verified it bites, not just that it passes: removing `separator` from apps.mdx fails with
exit 1 naming the variant; deleting a ledger entry fails as an undeclared union; mutating
a key fails as orphan + undeclared — the pair an author sees when adding a variant.

Known limit, stated in the script header: a variant counts as documented via
`<disc>: '<variant>'` or `` `<variant>` ``. The second form is loose and can match an
unrelated sentence for short generic variants — a pass means the page says the word, not
that it documents it correctly.

Refs #4001, #4165

Two conflicts, both in code #4165 ("reject unknown keys across the app shell
and navigation tree") rewrote underneath this branch:

- `packages/spec/src/ui/app.zod.ts` — main turned the nav union into a
  `z.discriminatedUnion('type', …)` with `.strict()` members and kept the
  `z.ZodType<any>` annotation; this branch replaced that annotation with the
  real `NavigationItem`. Both are kept. Reconciling them needed one addition:
  main widens the member array (`as unknown as readonly [ZodObject<ZodRawShape>,
  …]`) because the members are lazySchema Proxies and a superRefine-wrapped
  variant, and `discriminatedUnion` then reports the union's output as
  `Record<string, unknown>` — which fits `z.ZodType<any>` and nothing sharper.
  The union therefore takes a matching cast back to `z.ZodType<NavigationItem>`,
  documented at the declaration: every branch of the type is still
  `z.infer<typeof XNavItemSchema>`, so only the MEMBERSHIP of the list is
  unchecked, and app.test.ts parses all nine variants.

- `AGENTS.md` — main added the `check:generated` aggregate section; this branch
  added `check:exported-any` to the "pure checks with no generator" list. Both
  are kept.

Also registers `check:exported-any` in `check-generated.ts`'s ledger, which
main added and which reconciles itself against package.json on every run.

Registers `check:variant-docs` in the same ledger while here: #4177 added the
script and #4183 added the reconciliation, neither PR could see the other, so
`check:generated` was already failing on `main` itself. One line, in a file this
branch was editing anyway.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01XY3swmCsdYx6AMGiRmFt1H

…#4232)

The ledger is the campaign's map — which z.object sites are authorable (the
.strict() ratchet target), which are wire, which are deliberately open. Every
step reads it to pick the next move, and nothing kept it honest. It went stale
twice in one week: a classification verification disproved (hook.zod.ts carried
a blanket `authorable (p)` covering a runtime shape, #4207), and a "next step"
that had shipped months earlier (the unknown-key warning layer, #4218), which
sent the next reader off to rebuild something already in production.

A map that drifts is worse than no map, because it gets followed.

CHECKS. Site counts (the ledger states its own method — "z.object( occurrences
per file" — so every number is verifiable); coverage (every *.zod.ts with sites
in a triaged directory needs a row); section totals; and that a row claiming
"strict as of" names a file that really contains .strict().

The Class column is deliberately NOT checked. Authorable vs wire vs open is a
judgement about who writes the input, and this campaign's rule is
verify-before-tightening — encoding it would automate exactly the call that must
stay human. The gate protects the arithmetic and coverage so that judgement is
always made against current code.

Zero-site files are skipped: five of the six the first run flagged hold no
z.object at all (enum/token modules). Not a hole — the day one grows its first
z.object( it becomes undeclared and the gate says so.

FIRST RUN: 11 DRIFTS, in a file being actively edited by the campaign that owns
it. Six counts had moved (ui/app.zod.ts 11 → 18, ui/touch.zod.ts 4 → 7,
ui/action.zod.ts 8 → 9, ui/view.zod.ts 51 → 50, ui/responsive.zod.ts 6 → 4,
automation/flow.zod.ts 12 → 11), two section totals no longer summed, and
automation/io-node-config.zod.ts had no row. The app.zod.ts gap was
self-inflicted: the app step (#4165) added seven schemas and updated the row's
prose without touching its count.

Then it worked for real before merging: main landed
automation/builtin-node-config.zod.ts (#4045/#4228, eight sites), and merging
main turned the gate red on a branch whose own diff touches no schema. Now
classified. Every pre-existing count survived that merge unchanged, so the
failure was exactly as narrow as it should have been.

Verified the gate bites rather than just passes: a moved count fails (plus its
section total), a deleted row resurfaces as an undeclared file, and stripping
.strict() from approval.zod.ts fails its "strict as of" claim.

Refs #4001

…checked (#4244)

Follow-up to the #4177 variant/doc gate, using the signal it produced. That gate
passes a variant if the page contains either `<disc>: '<variant>'` or a bare
`` `variant` ``, and its header says plainly that the second form is loose: a
pass means the page says the word, not that it documents the thing. Six variants
were passing on the loose form alone — the gate's own "weak pass" list, and a
precise worklist.

apps.mdx enumerated nine navigation item types but only documented six. `report`,
`action` and `component` shared one sentence — "the spec also defines …" — while
the other six each had a section with an example. They now have their own, and
the intro no longer implies a second tier of half-supported types.

The `action` section earns its place: `actionName` lives inside a nested
`actionDef` block, not at the top level, which is exactly the shape a reader
guesses wrong. Both it and `component` note which sub-object stays OPEN by design
(`actionDef.params`, `component.params`) — the sibling contract owns those, and
after #4165 everything around them is strict.

knowledge.mdx had a table naming `object` / `file` / `http` and no example of
any, so the per-kind keys (`contentFields` vs `prefix` vs `urls`) appeared
nowhere. Added one example each.

Every example was parsed against the real schema before committing —
NavigationItemSchema and KnowledgeSourceKindSchema, six for six. Writing docs
from memory is how the region example in #4218 ended up using an `id` key that
does not exist.

Anchored-form coverage for these two unions: 9/12 → 12/12.

Carries an empty changeset. The first push asserted a docs-only PR needs none;
Check Changeset disagreed and named the fix — an empty changeset is the repo's
way for work that releases nothing, and 72 of them already exist.

Refs #4001, #4177